-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
indexing with a list of slices #10573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
(the bug has been fixed, apparently)
s for s in new_slices if len(range(*s.indices(size))) > 0 | ||
) | ||
elif isinstance(applied_indexer, integer_types): | ||
[selected_slice] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the integer is out-of-bounds, the raised error will complain about unpacking, it should raise an IndexError
instead
for reference, my initial use-case with So that means that contrary to what I said in the meeting today we can probably take our time here with a decision, I just don't want it to be forgotten. |
Following the discussion in #10479, this adds support for a list-of-slices container (tentatively called
MultipleSlices
) to most of the indexing wrapper classes. Still missing:PandasIndexingWrapper
.It didn't look like using a separate class as suggested in #10479 (comment) would be easy, and so I've decided to instead extend
_index_indexer_1d
to support, which turned out to be surprisingly easy.I'll still have to figure out how to best test this for the indexing wrapper classes other than
LazilyIndexingWrapper
, and I'm not really content with the API and the code duplication I have right now. I'll refactor that soon, but for now this works:cc @dcherian
whats-new.rst
api.rst